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Sun's Jini jousts with rivals 

By Stephen Shankland 

Staff Writer, CNET News.com 

January 25, 1999, 7:00 a.m. PT 



The race is on to create the universal fabric that 

could supplant today's ungainly networking technology, as Sun 

is set to debut its technology called Jini. 

Several companies, believing today's networking too cumbersome or limited, 
are working on technologies that connect everything from light switches to 
supercomputers in one ubiquitous network. The idea is to reap the benefits of 
ever-broader networks without having to deal with obtuse, unwieldy technology. 

But as often happens with high- technology efforts in their infancy, big-name 
companies will compete to establish their own vision of a universal network, 
thereby creating some confusion along the way. 

Many of the biggest names in computing are scrambling to set the standards 
and line up supporters including Sun Microsystems, Microsoft, 
Hewlett-Packard, IBM, and Lucent. 

After several previews, Sun will formally unveil its Jini technology in San 
Francisco today. Several companies, including networking software maker 
Novell, have licensed the Java-based technology, which allows the 
"spontaneous networking" of devices. And network hardware maker Cisco 
demonstrated a Jini -powered cable modem earlier this month, and Sun 
executives showed a free-standing Jini hard disk from Quantum in December. 

Sun says Jini will let traveling businessmen easily plug into hotel 
printers, let 

parents at work peek through child-monitoring cameras at home, and let people 
turn up the air conditioning before they get home. When a Jini -enabled device 
plugs into a network, it automatically announces itself and its capabilities. 

Meanwhile, Sun arch rival Microsoft, eyeing the approach of Jini, hastened to 
take the wraps off its Universal Plug and Play initiative at the Consumer 
Electronics Show earlier this month. Microsoft's technology is an extension of 
the Plug and Play hardware recognition system introduced with Windows 95, 
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but it will let people tie together devices without needing a computer. With it, 
devices announce themselves and their capabilities when plugged into a network. 

"We're looking at this with the view that all kinds of devices not currently 
networked today are going to want to be networked," said Alec Saunders of 
Microsoft's intelligent appliances division. Universal Plug and Play will 
work with 

"smart objects" such as light switches or volume controls, intelligent 
appliances 

such as Web-enabled telephones, or computers. 

Microsoft has found support from Compaq, Intel, ATI, 3Com, AMD, Kodak, and 
others . 

But Sun designed Jini from scratch, and therefore unlike Microsoft isn't 
hampered by having to support the "ancient" architecture of the PC, said 
Gartner Group analyst David Smith. 

"I see Universal Plug and Play as an evolution of technology, an incremental 
improvement to an OK solution. I see Jini as something that is much more 
elegant, part of the overall movement to network computing and ubiquitous 
devices," Smith said. 

Sun and Microsoft have similar intentions for their technologies: Both companies 
believe their network technologies will drive sales of more traditional products 
such as operating systems and servers. 

Microsoft criticized Java as an out-of-the blue technology where Universal Plug 
and Play uses existing Internet communications standards and 
registration services. "We're leveraging a big heritage of existing 
technologies, 

bringing Internet technologies into a new class of devices," Saunders said. 

Jim Waldo, Jini 1 s chief architect, though, spurned Universal Plug and Play as a 
mere initiative that checks all the boxes on the "buzzword bingo card." It's far 
behind Jini, which has had beta software out for months and will be 
launched as a 

product Monday, Waldo said. 

Microsoft says Universal Plug and Play devices won't need to 
have a computer on the network, but will be able to take 
advantage of one if it's there. 

Jini is designed to bypass computers altogether, Waldo said: "All we 
require is Java someplace on the network." 

Farther out into the future, Microsoft's research arm is working on 
another networking project, an operating ' system called Millennium that 
lets computers share tasks across a network, automatically adjusting to 
new components being added or removed. 

One Millennium prototype called "Borg" is a Java virtual machine that 

can make a cluster of computers look like a single one when running 

Java programs. Another prototype, called Continuum is similar, but 

adds support for other programming languages such as Visual Basic, C, and C++. 

Sun and Microsoft have the most prominent efforts, but they aren't the 
only big names in the business of redefining how networks happen. 
HP, Lucent, and IBM all have plans of their own. 

HP's r JetSend 



Hewlett-Packard introduced its Set Send 

technology in 1997 as a way to shield users from the complexities of 
different document formats, said HP's Kipp Martel . The technology 
complements both Universal Plug and Play as well as Jini, Martel said. 
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The technology lets two devices ne gotiate the best way to share 

documents so, for example, a ^tSc»^- enabled 

printer could accept an image from a SetSend- enabled digital 

camera. The two devices communicate to figure out what 

common format will preserve the image quality best. Jet Send 

also could let a cable TV operator send video on demand over a network 

without having to worry about what devices the viewer will use. 

While the company has deployed Jet Send in its own printers and, more 
recently, scanners as well, HP will next move JetSend into 
computers this spring, Martel said. This will allow the computer to 
take over JetSend communications for non JetSend- enabled devices, he said. 

Jetsend is the Esperanto of the computing world, Martel 
said, promising "universal viewability, " Martel said. HP's 
•Je t S end - enabled CapShare 910 hand-held scanner 
transfer's scanned images to computers using Adobe's 
cross -platform Portable Document Format (PDF) . 

SetSend has been licensed by several companies, including 
Panasonic, Minolta, Siemens, Xerox, and Canon. 

HP will support CapShare both for Jini and Universal Plug and 
Play, even though it costs more to support two platforms, Martel 
said. "We are committed to this vision of a world of seamless 
connectivity, " he said. 

Lucent ' s Inferno 

Lucent's Inferno effort gives equipment such as smart phones, 
Internet appliances, or set-top boxes a small -footprint operating 
system that can connect to networks or run programs within a virtual 
machine. The system currently supports programs written in Lucent's 
Limbo language or Sun's stripped-down version of Java called 
Personal Java. 

Inferno was publicly announced in 1997, but Smith has seen little 
progress since. "It's a fantastically well-designed piece of work. It's very 
applicable in today's world of the Internet, it's just that Lucent has not 
been able to market it," Smith said. 

Lucent declined to comment for this story, but said Inferno can be 
used in a lot of the same ways as Jini. "Right now we're in the process 
of working on applications and technology related to specific markets, 
but it would be premature to comment on that now, " said 
spokeswoman Barbara McClurken. Lucent expects to make a new 
Inferno announcement in "a couple of months," she said. 

IBM's T Spaces 

IBM's research wing, meanwhile, is working on a Java-based 

technology called T Spaces that lets computers, digital assistants, and 

other devices share data such as email or database queries. 

The technology complements Jini and helps to achieve the common 

goal of "pervasive computing." However, T Spaces is only one of IBM's 

projects from its research labs that applies to that future world. 

An IBM paper notes that T Spaces "basically connects all things to all 
things," and can run on very small devices. The technology would 
make it easy for resources such as printers, scanners, fax machines, or 
software services to be shared across networks with lots of different 
kinds of computers. 
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All these different technologies have appeal, Gartner Group's Smith 

said, but are likely to show up first in homes and small offices. It's hard 

to manage systems of thousands of devices attached to networks, he said. 

But as the systems catch on, they'll likely "trickle up" to higher levels as 
the networking technologies become more robust and pervasive, he said. 

"There is a tremendous desire to move us toward easier-to-use 
networking," Smith said. 

Intel has a technology too which it is promoting as the "Home Network 
API" in an effort to develop a common method for computerized 
control of home devices and Sun and Philips are providing a similar 
technology called HAVi . 



(from Table) 
Sun - Jini 

Lets any Jini -enabled device or software module share services 
for "spontaneous networking" with other Jini devices. 

Microsoft - Plug & Play 

Extends hardware recognition beyond PCs to let electronic devices 
easily connect without needing a computer. 

Microsoft - Millennium 

Lets collections of computers automatically divvy up computing tasks 
across network. 

IBM - T-Spaces 

Java-based system that allows computers, palm computers, 

or other devices to share messages, database queries, print jobs, or other 
network services. 

Lucent - Inferno 

Small -footprint network operating system to let smart phones, set-top boxes, 
and other equipment plug into the network and run Java or other programs. 

HP - JetSend 

Communication technology that let s_ networked devices such as printers, 
scanners, or digital cameras riegotiat| common file formats for data 
exchange . 
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JETSEND is a device-to-device communications protocol for local and wide area 
networks, that allows network devices to intelligently negotiate information 
exchange between them, without the need of involving a separate computer to 
negotiate the conversation. The JETSEND protocol allows the two devices to 
connect over a network, negotiate the best possible data type, provide device 
status, and exchange information, all without intervention from a user or from 
a third device such as a computer to negotiate the communication between the 
two devices. JETSEND protocol is described at length in "HP JETSEND.TM. 
Communications Technology, Section I: Architectural Overview; Section II: 
Protocol References; and Section HI: E-Material Specification", Version 1.0, 
Hewlett-Packard Company, 1997. These documents are incorporated by reference 
as if set forth in full herein. 

As an example, a JETSEND-enabled scanner (or other image input device such as a 
digital camera) can capture image information and then send the image 
information directly to a JETSEND-enabled printer (or other output device such 
as a facsimile or a projector) at a remote network location. According to the 
JETSEND protocol, the scanner would send information about its capabilities to 
the printer. Such information would include, for example, the available 
formats, color capabilities, bit length, and image resolution, of images that 
the scanner could acquire. In response, the printer would return information 
concerning the format in which the image information should be sent. The image 
information is captured by the scanner and thereafter sent directly to the 
printer for output. All such communications occur without the intermediary of 
a user or a computer such as a server to negotiate the communication, thereby 
enabling the scanner to communicate directly with the printer. 

One problem currently being encountered with JETSEND concerns modification of 
legacy systems, which do not incorporate JETSEND protocol, into JETSEND-enabled 
systems. For example, current networked printers represent an enormous 
installed base of network printers that are not currently JETSEND-enabled. 
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a program memory for storing process steps executable to perform (a) a 
monitoring step to monitor control byte information as the compressed image 
data is being stored to a buffer, so as to determine when the end of a scan 
line has been reached; (b) a modifying step, responsive to the end of a scan 
line being reached, to modify the control byte of the final portion of 
compressed image data in the buffer so as to correspond to exactly one scan 
line; (c) a transmitting step to transmit image data in the buffer prefixed by 
a printer description language command that includes a byte count of the number 
of bytes in the transmission; and (d) a starting step to start a new scan line 
in the buffer beginning with any un-transmitted data together with a control 
byte that specifies either a repeat count or a byte count in correspondence to 
whether the un-transmitted image data was run length encoded or a literal 
representation, and followed by newly-received compressed image data; and 

a processor for executing the process steps stored in said program memory. 

10. A computer-readable medium for storing computer-executable program code, 
said computer-executable program code for converting compressed image data into 
a compressed raster image in units of a scan line, the compressed image data 
including mixed portions of run-length encoded representations in which a first 
byte is a control byte that specifies a repeat count and a second byte is image 

data to be repeated, mixed together with literal representation portions in 
which a first byte is a control byte that specifies a byte count of 
uncompressed image data bytes that follow, said computer-executable program 
code comprising: 

11. Computer-readable program code according to claim 10, further comprising: 

12. Computer-readable program code according to claim 11, wherein modification 
comprises flipping black and white bits of the compressed image data. 
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Communications Programming Concepts 



Chapter 8. Remote Procedure Call 

Remote Procedure Call (RPC) is a protocol that provides the high-level communications paradigm used in the 
operating system. RPC presumes the existence of a low-level transport protocol, such as Transmission Control 
Protocol/Internet Protocol (TCP/IP) or User Datagram Protocol (UDP), for carrying the message data between 
communicating programs. RPC implements a logical client-to-server communications system designed specifically f 
the support of network applications. 



This chapter provides the following information about programming RPC: 



• RPC Model 

• RPC Message Protocol 

• RPC Authentication 

• RPC Port Mapper Program 

• Programming in RPC 

• RPC Features 

• RPC Language 

• rpcgen Protocol Compiler 

• List of RPC Programming References 



The RPC protocol is built on top of the external Data Representation (XDR) protocol, which standardizes the 
representation of data in remote communications. XDR converts the parameters and results of each RPC service 
provided. 

The RPC protocol enables users to work with remote procedures as if the procedures were local. The remote 
procedure calls are defined through routines contained in the RPC protocol. Each call message is matched with a re 
message. The RPC protocol is a message-passing protocol that implements other non-RPC protocols such as batchin 
and broadcasting remote calls. The RPC protocol also supports callback procedures and the select subroutine on the 
server side. 

A client is a computer or process that accesses the services or resources of another process or computer on the netwo 
A server is a computer that provides services and resources, and that implements network services. Each network 
service is a collection of remote programs. A remote program implements remote procedures. The procedures, thei 
parameters, and the results are all documented in the specific program's protocol. 

RPC provides an authentication process that identifies the server and client to each other. RPC includes a slot for the 
authentication parameters on every remote procedure call so that the caller can identify itself to the server. The clie 
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package generates and returns authentSRon parameters. RPC supports various^pes of authentication such as the 
UNIX and Data Encryption Standard (DES) systems. 

In RPC, each server supplies a program that is a set of remote service procedures. The combination of a host address 
program number, and procedure number specifies one remote service procedure. In the RPC model, the client mak 
a procedure call to send a data packet to the server. When the packet arrives, the server calls a dispatch routine, 
performs whatever service is requested, and sends a reply back to the client. The procedure call then returns to the 
client. 

The RPC interface is generally used to communicate between processes on different workstations in a network. 
However, RPC works just as well for communication between different processes on the same workstation. 

The Port Mapper program maps RPC program and version numbers to a transport-specific port number. The Port 
Mapper program makes dynamic binding of remote programs possible. 

To write network applications using RPC, programmers need a working knowledge of network theory. For most 
applications, an understanding of the RPC mechanisms usually hidden by the rpcgen command's protocol compiler 
also helpful. However, use of the rpcgen command circumvents the need for understanding the details of RPC. 
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An Introduction to the JetSend 
Protocol 

John Meadows 

JetSend is a media-independent 
communications protocol that can 
exchange information in its proper 
context without any 
product-specific knowledge or 
device drivers. This article provides 
an overview of the JetSend protocol. 

JetSend is a media-independent 
communications protocol, developed by 
Hewlett-Packard, that provides interoperability 
among a wide variety of devices in differing 
vertical markets. You may be thinking, "Do we 
really need another communications protocol?" 
The answer is yes, and here is the reason: a 
need exists for a protocol that supports 
device-to-device content exchange. True, 
protocols already exist for point-to-point data 
exchange (FTP, IrTranP, and so on), but the 
problem with these protocols is that they don't 
fully describe the content being exchanged, and 
as a result the data transferred is both machine 
dependent and OS dependent. 

The fact that JetSend is able to exchange 
information in its proper context, without any 
product-specific knowledge or device drivers, 
gives it tremendous value. Increasingly, 
embedded devices are required to exchange 
data with other devices directly (that is, no PC 
will be required). With JetSend, the user of a 
device doesn't need to know what protocol is 
being used to transfer data. These devices 
might be digital cameras, cell phones, PDAs, 
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just a few. Another compelling reason for using 
JetSend is that it already has support in many of 
the devices just listed. All of Hewlett-Packard's 
standalone printers and scanners support 
JetSend. Also, JetSend printer support for 
Windows CE PDAs-although not native-can be 
obtained via download from HP. This article will 
attempt to provide an overview of the JetSend 
protocol. 

Overview of JetSend 

The HP JetSend protocol is a peer-to-peer 
communication protocol. The protocol allows 
two devices to connect, negotiate data types, 
and exchange information. With this new 
protocol comes a new paradigm for job control 
in embedded devices. For example, say a person 
wants to print a picture from a digital camera. 
The current job control model requires the user 
to transfer the picture to a printer through a 
two-step process. First the user must launch a 
compatible digital camera application on a PC to 
receive the desired pictures from the camera. 
Then a host application-possibly the same 
one-prints the desired pictures using a 
compatible printer driver. In this job model, the 
host computer acts as a translator between two 
devices that speak different languages. 

The JetSend job control model differs in that it 
is a one-step, peer-to-peer communication 
process. A host PC no longer controls the 
exchange of data between two devices, which 
removes the need to load a special driver on the 
sending device because both devices speak a 
common language. One side effect, however, is 
that the host PC can no longer be relied upon for 
any data translation. 

Within JetSend, all data exchanged between 
devices is accomplished using surfaces. Each 
surface object has a name, a description, and 
content. The description is analogous to a file 
header, and contains information about the type 
and content of the surface. The content portion 
may be null, data, or a reference to another 
surface (a child surface). The data contained in 
a surface is called electronic material 
(e-material). 

As an example, a two-page document, one with 
image and text and the second with just an 
image, can be represented by six surfaces, as 
shown in Figure 1 . The encodings of the 
surfaces are also shown. In a printing example, 
the vAssociation encoding describes the entire 
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document or print jod. i ne vnane encoding 
controls the layout of pages to be printed. The 
vlmage and vText encoding describe the 
content of the image and text. 

In this example the "Textl" child surface on the 
first page of the document is a text description 
of the "Imager picture. This description might 
be something like "Billy's first birthday-January 
01, 1999." A raster image of this text string is 
also offered in case the receiving device does 
not support the vText encoding. In other 
nonprinting applications, surface encodings may 
take on different meanings. 

Surface interaction model: the rules 
of the language 

JetSend is a layered protocol designed to be 
machine independent as well as transport 
independent. The components of the protocol 
shown in Figure 2 are as follows: 

• The device-specific code is the application 
itself 

• The Interaction Policies control the method 
of interaction between devices by enforcing 
certain types of policies. One of the 
policies-the Job Policy-will be covered in 
detail in the section on using the JetSend 
API 

• The e-material routines allow the 
device-specific code to format data to be 
communicated in a standard JetSend 
format that another JetSend enabled device 
will be able to understand. Surfaces are 
e-material 

• The JetSend Interaction Protocol (JIP) 
manages the sending and receiving of 
surfaces 

• The JetSend Session Protocol (JSP) is 
responsible for managing a reliable data 
connection with a remote device 

• Transport Independent (TI) layer decouples 
the JetSend stack from the OS-dependent 
network layer 



Data sent by the application layer 
(device-specific code) must progress down 
through each layer before being sent out over a 
transport medium and then back up through the 
JetSend stack of the receiving device. 

Machine independence is achieved through the 
use of e-material, which specifies data types 
and formats that do not rely on software 
language data types. An example of this would 
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be the e-material definition of a simple integer 
type. The first byte of the type definition is a 
value type identifier, which tells what type of 
integer it is, as shown in Figure 3 . The byte(s) 
that follows is the actual value of the integer in 
network byte order (big endian-most significant 
byte first). 

The TI layer is responsible for providing a 
generic API to the non-JetSend transport 
protocols. Operating system-specific code is 
needed to translate generic TI API messages 
into OS network driver calls and vise versa. 

Using the JetSend API 

To communicate using JetSend, device-specific 
code must interact with an API composed of 
three main sections: the Activity Manager, 
Interaction Policies, and e-material routines. 

Activity manager API . The Activity Manager 
is the heart of the JetSend API and fulfills two 
main functions. First, the Activity Manager is 
responsible for managing JetSend sessions. A 
session is a reliable full duplex communication 
channel established between two 
JetSend-enabled devices. All user data 
transferred from one device to another is 
conveyed over one or more sessions. The 
second main function is event handling. The 
Activity Manager manages events coming from 
the lower layers of the JetSend stack by 
providing an event queue and polling 
mechanism to process and free events. Listing 1 
shows the routines that make up Activity 
Manager API. More about how the Activity 
Manager works will be discussed in the section 
on sending application data. 

JetSend interaction policies . The second 
main section of the JetSend API is concerned 
with supporting one or more of the JetSend 
Interaction Policies. This component of the 
JetSend Protocol defines various typical 
sequences of interactions that devices agree to 
follow. Most of the toolkits available implement 
the session policy and a portion of the job 
policy. Altogether five policies have been 
defined as follows: 

• Session policy-how to establish and 
disconnect sessions between devices 

• Job policy-how to send documents between 
senders and receivers 

• Self policy-how to exchange global 
information about a device, such as label, 
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icon, and passwords 

Status policy-how to give status about a 
device and about jobs 
Address policy-how to program devices 
with new destination addresses 



Of the five policies, the session policy is 
supported directly by the Activity Manager 
through the use of session management 
routines. The session policy defines how 
sessions are created and destroyed. In the 
session policy, roles for both passive and active 
devices are defined. The passive device acts as 
a consumer and the active device acts as a 
producer. In order for two devices to 
communicate, one device must begin listening 
for another device to connect to it on a given 
transport channel. The listening device opens a 
passive session and waits for notification of a 
connecting device. 

The remaining policies-job, self, status, and 
address-define how data is formatted and 
exchanged between devices. 

The job policy is used to send and receive 
application data over JetSend sessions. Two 
methods for exchanging data, the PUSH method 
and the PULL method, are defined by the job 
policy. As the name implies, the PUSH method is 
used to push data from a sending device to a 
receiving device, as would be done for printing, 
faxing, and so on. I will give an example of a 
PUSH sender/receiver in the section on sending 
application data. The PULL method is used when 
the receiving device needs to be able to select 
certain pieces of data from a sending device, as 
would be the case for some type of monitoring 
device. An example of this might be a 
JetSend-enabled digital Walkman that is able to 
download selected songs from a jukebox-like 
storage device using the PULL method. 

The self policy, status policy, and address policy 
together provide the mechanisms to convey 
device attribute and status information. The self 
policy provides the ability for a remote device to 
obtain device attribute information. This 
information includes the device's address, name 
(in text and in a Windows icon bitmap), and PIN 
number to allow support for user authentication. 
The self policy is often used in conjunction with 
the address policy. 

The status policy, as the name implies, allows a 
device to obtain the status of another device. 
Using this policy it is possible to report 
conditions like paper jam, low battery, and so 



An Introduction to the JetSend Protocol 



http://www.ernbedded.corn/internet/000 1 /000 1 ia2 



on. 

The last policy in this grouping, the address 
policy, defines a mechanism to convey 
addressing information about additional devices 
available on a network. The JetSend protocol 
doesn't have a mechanism to automatically 
discover JetSend devices on a given network, so 
the address of at least one JetSend device must 
be known in order to use JetSend to accomplish 
a given task. Users program a device with the 
addresses of the devices they wish to use. For 
point-to-point transports like IrDA, this is as 
simple as programming a single default address 
into the device. On network transports like IP, 
the address policy can be used to program 
devices with additional addresses. The address 
policy allows a network administrator to set up a 
well-known device address on a network that 
holds the addresses of other JetSend devices. 
Once addresses are obtained, the type and 
capabilities of a device can be discovered by 
using the self policy. 

E-material routines . The e-material routines 
are used to create and parse surfaces in order to 
intelligently exchange data. E-material data 
structures have predefined data elements and 
data types that include values, strings, and lists. 
Using e-material routines, simple data types like 
integers and strings are converted to e-material 
types to build surface descriptions. E-material 
surface descriptions are constructed to fully 
describe user data and list possible encodings in 
which the sending device can transfer the data. 
This gives the receiving device the ability to 
choose an encoding that best suits its devices' 
capabilities. The process of selecting a data 
transfer format is called device negotiation . 
To ensure that devices of the same class will be 
able to exchange data, a default data format is 
defined. For example, the default encoding for 
image devices is 300 x 300 dpi, monochrome, 
RLE compressed raster data. All 
JetSend-certified image devices (printers, 
scanners, copiers, cameras, whiteboards, and so 
on) must be able to send and/or receive this 
encoding (Section 2.2.3 of the JetSend Protocol 
Specification, v. 1.5). The ability to add new 
encodings while enforcing support for a default 
encoding will allow JetSend to maintain 
backwards compatibility. You have a device like 
a digital Walkman that supports audio clips in 
MP3 format. The sending device might support 
new audio formats while still supplying the old 
digital Walkman with MP3 audio clips. The new 
digital Walkman can thus take advantage of a 
new format, while the old devices-having only 
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the old format-are still supported. 



Sending data 

The sample PUSH sender given in Listing 2 will 
be used to describe the steps required to 
transfer user data from one device to another 
(see also Figure 5 ). At the beginning of the 
routine RunSimpleSender() the Activity 
Manager, which is responsible for managing 
sessions, is initialized by calling jamlnitialize() 
. This sets up an event queue inside the Activity 
Manager that can be polled by the 
device-specific code using the function 
jamGetNextEvent() . This polling mechanism 
allows the device-specific code to process events 
that have propagated up through the JetSend 
stack. Next, the PUSH sender is initialized by 
calling pslnitialize() . Upon initialization the 
PUSH sender installs callbacks for events it will 
handle as part of the job policy (shown , 
graphically in Figure 4 ). To communicate from 
one JetSend-enabled device to another, an 
active JetSend session must be created, which is 
accomplished by calling jamStartSession() . 
The transport address is specified in this call. In 
this example IrDA is selected as the transport. 
For a session to succeed in opening, a JetSend 
receiver must be listening for a session on the 
same network channel selected in the 
jamStartSession() call. 

When a session is first established (that is, the 
session opens successfully) the PUSH receiver 
constructs an "IN" surface and sends it over the 
newly opened session. The purpose of the IN 
surface is to inform the connecting device that a 
receiver is available which supports the job 
policy. Upon receiving the remote device's IN 
surface, the PUSH sender posts a 
psInArrivedEvent event to the Activity 
Manager. The sending device-specific code then 
reads this event via jamGetNextEvent() and 
begins the process of sending a document. 

To illustrate how a document is sent, let's once 
again use the document in Figure 2 . The 
vAssociation surface is constructed using 
routines from the e-material library and then 
sent out over the open session to the remote 
device. The PUSH receiver, called by the Activity 
Manager via a callback routine, posts a 
prJobStartEvent when the vAssociation 
surface is received. The remote device code, in 
processing this event, parses the vAssociation 
surface description and determines what portion 
of the data it wishes to receive. 
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For this example we will assume that the 
receiving device will ask that the entire 
document be sent through a series of requests 
to the sending device. First the receiver 
requests the first vPlane surface (or page) in 
our document. The sender receives this request 
as a psSurfaceRequestEvent from the 
jamGetNextEvent() routine. A description of 
the data contained in the requested vPlane 
must then be constructed via e-material 
routines and sent to the remote device. The 
vPlane description defines how a page is laid 
out. In our sample document this description 
would contain (x,y) coordinates of both the 
image and text objects. The receiving device 
then knows where to place the objects for 
display or printing. At this point the receiver has 
the knowledge that the current job consists of a 
two-page document, and that the first page has 
both an image object and a text object on it. So 
far, no user data (content) has been transferred. 

In the next step, the sending device requests 
the vlmage surface which contains a description 
of the image data. This description is in the form 
of a list of possible encodings supported by the 
sender. The receiving device reads the list of 
data encodings and requests that the content be 
sent in a format that best suits its device 
capabilities. The sender-upon receiving a 
request-sends content messages until the entire 
body of the vlmage is sent. The remote device 
then requests the vText surface be sent. Our 
example document has the text content as part 
of the vText object on page one, so once the 
vText surface is sent, the first page is fully 
transferred and can be displayed, printed, or 
stored. Since there are two vPlanes in the 
vAssociation surface of our example document, 
the remaining vPlane will be requested using 
the same techniques. 

When all the data is sent, the session can be 
closed or left open. A session would be left open 
if additional data were to be transferred. For 
example, the sending side could have additional 
documents (or jobs) that it desires to send. The 
additional documents would be sent in the same 
manner as I previously described. The 
possibility also exists that the receiver would 
want to get updates of any changes made to a 
received document by the sending device. An 
example of this might be a JetSend-enabled 
display connected to a portable computing 
device. 
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A few good reasons 



The JetSend protocol is well suited for 
embedded devices for a couple of reasons. First, 
the protocol has been kept simple by defining 
everything in terms of surfaces. Therefore, a 
typical implementation of the JetSend stack on 
an embedded device will be somewhere around 
60K of code. The second reason is that JetSend 
is peer to peer, and will allow devices to 
communicate with a range of other devices, a 
feature which will likely become a requirement 
as the number and usage of new devices 
increase. The third reason why JetSend is a 
good fit for embedded devices is the negotiation 
aspect of the protocol. Negotiation allows 
embedded devices to support a small minimum 
set of data formats that will be directly used by 
the device. For example an image class device 
does not have to support TIIF, JPEG, GIF, 
Windows bitmap, and so on, but only needs to 
be able to support raster image data in at least 
the minimum 300dpi RLE encoding. As long as 
memory is not free, the negotiation feature of 
JetSend will allow embedded devices to 
communicate with a wide variety of other 
devices at a reasonable cost. ' 



So far I have covered only a few of the possible 
uses of JetSend. Hewlett-Packard continues to 
develop the protocol and has added JetSend 
support to many of their printers and scanners. 
New e-material encodings such as vCard and 
vCalendar are currently being added to the 
specification to enable the exchange of contact 
and calendar information. A new interaction 
policy, the control policy, has been developed to 
support reimote control of JetSend-enabled 
devices. Also added to the specification is 
support for proxies. As an example, an e-mail 
proxy can be used to provide e-mail support for 
devices that do not support e-mail, but do 
support sending to proxies. To learn more about 
these new features, as well as for additional 
information on JetSend, visit www.jetsend.com . 

John Meadows is a member of the technical staff 
in the E-Services Practice at Questra Corp. He 
has almost 14 years of experience in the 
industry, focused primarily on networking and 
communication protocols. Prior to joining 
Questra, he worked as a software specialist for 
Redcom Laboratories which designs and 
manufactures Telecom switching equipment for 
hostile environments. John has an ASEE from 
Alfred State College and a BSCS from the 
Rochester Institute of Technology. 
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Figure 1 : - Two- page document: with images and text 



Figure 2 : The JetSend protocol stack 
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Figure 3 ; JetSend integep encodings;, 



Figure 4 : The PUSH sender installs callbacks for events it will 
handle as part of the job policy 



Figure 5:Jet Send transaction ■ ^_ 



Listing 1 : Activity Manager API routines 



Listing 2 : Sample PUSH sender 
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FIG. 3 illustrates the architecture of software for an image input device such 
as scanner 104, as stored in and executed by the NIC. Such software is stored 
as computer-executable process steps in a computer readable medium, such as the 
aforementioned EEPROM 16. As shown in FIG. 3, the architecture of the software 
extends through the NIC between the LAN and the networked input device, so as 
to provide interface for the networked device to the LAN. Thus, the 
architecture of the software includes physical layer 31, plurality of different 
protocol stacks 32, JETSEND interaction protocol 34, and device-specific 
applications such as scanner control application 35. Device-specific 
applications are applications concerning the functionality of the network 
device, such as the aforementioned scanner control application 35. 

Plural protocol stacks 32 are preferred since they increase the flexibility of 
a networked device by allowing it to communicate via the network interface on 
the LAN using plural different network protocols. In the FIG. 3 example, two 
different network protocol stacks are shown, including IPX protocol stack 36 
and IP protocol stack 37. Other protocol stacks may also be provided, such as 
a DDP protocol stack, a UDP protocol stack, a NetBIOS protocol stack, or an 
AppleTalk protocol stack . Of course, it is possible for a networked device to 
operate over even a single protocol stack . 

FIG. 4 illustrates the architecture of software for an image output device such 
as printer 1 15, as stored in and executed by the NIC for the printer. In much 
the same way as the software for image input devises, such software is stored 
as computer-executable process steps in a computer readable medium, such as in 
EPROM 16. As shown in FIG. 4, the architecture of the software extends through 
the NIC between the LAN and the networked output device, so as to provide 
interface for the networked device to the LAN. Thus, the architecture of the 
software in FIG. 4 includes physical layer 41, a plurality of different 
protocol stacks 42, device-specific applications such as printing control 
applications 44, a JETSEND interface protocol 45, and a JETSEND agent 46. The 



NIC further includes a printer interface module such as XP module 47. XP 
module 47 provides process steps for a standard interface between the NIC and 
the printer. In particular, and as illustrated in FIG. 4, the printer includes 
a print engine and a print controller, and XP module 47 interfaces directly to 
the print controller over whatever interface is provided therebetween, such as 
the aforementioned bi-directional interfaces or the aforementioned 
uni-directional interfaces. 

In much the same way as plural protocol stacks increase the flexibility of a 
networked input device, plural protocol stacks 42 increase the flexibility of a 
networked output device such as the printer, by allowing the NIC to communicate 
via the network interface using plural different output protocols. Again, in 
FIG. 4, two different protocol stacks are shown including IP protocol stack 48 
and IPX protocol stack 49. Other protocol stacks may also be provided; and it 
is further possible for the networked output device to operate over even a 
single protocol stack . 

In the FIG. 1 example, printer control application 44, JETSEND interaction 
protocol 45 and JETSEND agent 46 are all shown as operating over the IP 
protocol stack 48. It is to be understood that this is representative only, 
and it is typical for printer control applications, JETSEND interface 
protocols, and JETSEND agents also to operate over each of the different 
protocol stacks included in the NIC. 
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